BMUG PD-ROM BV3

home *** CD-ROM | disk | FTP | other *** search

/ BMUG PD-ROM BV3 / BMUG PD-ROM Version BV3 (CDRM1097900).iso / Telecom / Compacting Programs / MacBin / MacBinary II Conference 2 < prev next >

Wrap

Text File | 1989-04-23 | 34KB | 686 lines

(18,Neil/Sysop) This is the second CO on the new MacBinary2 standard, conducted by... representatives from the CompuServe, Delphi and BIX networks.... with representation from various companies and developers... We'll at least start off with formal roundtable procedures... meaning that the moderator (me because that's about all I can do) will... ask who has comments and then call on each in order... Don, now that we are recording could you please take the "floor" a... second and introduce the "Amendment" sheet with maybe a leading comment as to what it relates to from last week? thanks..over to you. ga (18,Don Brown/Sysop) OK, we worked out a proposal last week for a minor... modification to MacBinary that would handle the new... Finder bits, as well as making some provision for... future expansion. That proposal was published here... on CIS, and I presume was also posted on Delphi and BIX. Is... everyone familiar with that proposal (before changes),... or should I repeat it now? If you want it repeated,... please type "Yes" (18,Neil/Sysop) I think yes just for transcript purposes, maybe. (18,Don Brown/Sysop) Okay, here is the current proposal: The new standard will be very similar to the original MacBinary standard (as described in MACBIN.STD, DL3 of AppDev), with the following bytes now defined: Offset 99-Byte, Finder Flags, bits 0-7. (Bits 8-15 are already in byte 73) Offset 122-Byte, Version number of uploaded Macbinary (starts at 129) Offset 123-Byte, Minimum MacBinary needed to read this file (starts at 129) Offset 124-Word, CRC of previous 124 bytes All Finder flags and information would be uploaded, however, a downloading program should clear the Finder flag bits of 0 - Set if file/folder is on the desktop (Finder 5.0 and later) 1 - bFOwnAppl (used internally) 8 - Inited (seen by Finder) 9 - Changed (used internally by Finder) 10 - Busy (copied from File System busy bit) Also, fdLocation and fdFldr should be zeroed To determine if a header is a valid MacBinary header, check bytes 0 and 74 to be both zero. If they are both zero, either (a) the CRC should match, which means it is a MB II file, or (b) byte 82 is zero, which means it is a MB I file. (Note that, at the current version level, byte 82 is kept zero to maintain compatibility with MacBinary I. If at some point the MacBinary versions change sufficiently that it is necessary to keep MacBinary I programs from downloading these files, we can change byte 82 to non-zero.) If the header is a MB II header, the program will check the minimum version byte, to see if it knows enough to decode the file. If the minimum version in the header is greater than the version that the terminal program was written for, it will download the file as pure XModem (creating a "TEXT" file) and notify the user that conversion is needed because the MacBinary version was too high. That is the proposal as worked out last time. In... discussions on the board since then, the... following changes have been suggested: Ammendment#0 Bit 6 should NOT be cleared. Ammendment#1 The word at offset 120 will hold the length of a secondary header, to be skipped when decoding a MBII file. This is for future expansion, if we decide to add a second header, but that the information in such header is not vital to decoding a MBII file. (Of course, such a change WILL involve making the files incompatible with MacBinary I.) MBII should currently zero this number. Ammendment#2 The longword at offset 116 may optionally hold the total disk space used by all files if the MBII file represents a packed, compressed set of files. This is for the convenience of any program that packs and unpacks on the fly and can be ignored by most implementations of MBII. If the value here is zero, it means that this value is Unknown. MBII uploading programs that do not have a proper value to fill this field with must make sure it is zeroed. We are not trying to limit changes here, if you... have other changes, we can do that too, but... this is my best understanding of the general consesus at... this time. ga (18,Mark Hagerman) With reference to offset 116... should it be zero as well for non-packed files? ... After all, the length IS known. ga. (18,Don Brown/Sysop) We could go either way, but I'd suggest saying 0, so that... a program that decodes on the fly knows whether this is a... file that was packed separately and uploaded (so that... the length would otherwise represent the length of... the packed file), or is a packed-on-the-fly file. So,... only if the uploading program absolutely knows the total length... if unpacked should it be non-zero. (18,Mark Hagerman) I'd suggest -1 to flag as non-packed, 0 for packed unknown. (18,Don Brown/Sysop) Mark, how does the terminal program know if it's packed unknown? (18,Mark Hagerman) I don't understand the question. (18,Don Brown/Sysop) I don't think I expressed myself clearly. Let... me give a scenario, if I might. I pack six files together with Packit III, which... have an unpacked size of 100K, but packed together... have a length of 75K. I then upload with MockTerminal,... that has no way of knowing that this file I'm sending... is a packed file as opposed ot a normal data file. You then... download it with WonderTerm, that unpacks on the fly. It... sees the length longword as saying 75K, and since the disk... has 78K, starts the download. It then starts download,... unpacking on the fly, then runs out of space. Was that... any clearer? (18,Mark Hagerman) yah. I guess I don't see that "WonderTerm"... will do the on-the-fly unpacking, since... the flags in the header won't have been set... by MockTerminal. (18,Don Brown/Sysop) The assumption is that WonderTerm, seeing that the... file it's about to download has a type of PIT and... knowing the format of Packit 3 files, will unpack it on... the fly. WonderTerm will be keying off of the File type, just... like the file type is used to determine whether... Packit will try to unpack a certain file. (18,Mark Hagerman) But file type PIT is specific to PackIt, nicht wahr? Or at least, that format. (18,Don Brown/Sysop) Mark, yes, but it's been published, so anyone who... wants to (and I want someone to SOOO BAAADDDD) could... recognize the file type and unpack it on the fly. (18,Mark Hagerman) What about other packing algorithms? (18,Peter Olson/ICONtac) two comments ... I think the field should be zero if the ... file is not packed. it should only be ... used for a length if the originator wants ... to give the receiver helpful information ... about unpacking second comment: I plan to do some measurements of relative performance of ... other packing algorithms in the next month or so ... including the LZW's etc from ARC (18,Don Brown/Sysop) OK. Mark, the same scheme would work... equally well for any packing scheme, only the... file type would be changed to protect... the innocent. ga (18,Harry Chesley) Two comments: (1) The PackIt file format is specifically set up to handle... multiple formats of subfiles. This could include different compression... schemes, or something completely different. It's already been used to add... encryption. (2) Don: This is not a challenge but a question: What does the new format buy you... that concatenating the current MacBinary and the current PackIt together... doesn't. The current PackIt does include all 16 Finder flags. The big... advantage of this approach would be that you either have a new MacBinary... program that unpacks things for you, or (worst case) you use the old... program and the new PackIt (or unpit). You do loose knowledge of the... final size (an admitted flaw in the PackIt file format), but what else? ga (18,Don Brown/Sysop) First of all, it gets us all sixteen finder flags... when we AREN'T packing files together, and if you'll... recall from last time, there was an overwhelming... consensus that we did NOT want to tie the new format... into forcing a compression/packing algorithm. Secondly,... the loss of the final file size is a significant disadvantage... once most people are switched over to the new system. Finally,... it minimizes compatibility problems in the interum, which... is of vital importance. Old programs will be around for... a long, long time, and we must do whatever we can to... minimize their problems, or else support departments... and sysops develop prematurely gray hair (IMHO). (18,Harry Chesley) I don't have any strong feelings about this, and definitely don't want... to force it if people want a clear separation of MacBinary and PackIt, but... I want to make sure people understand that what we have right now (i.e., MacBinary/PackIt) does solve the primary problem being posed. All that is... needed is new versions of the unpacking programs PackIt (coming out soon as... V1.3) and unpit. That seems like a very simple solution in terms of... educating users. If you want to separate compression, you can simply... put two layers of PackIt around a file, one for packing and one for... compression. It's not much different than one layer of MacBinary and... one of PackIt. The final size is a definite plus, I agree. Is it worth... a new protocol?... Anyway, as I said, I don't want to force things, so I'll back off, having... said that. I just wanted to be sure people understood it. ga (18,Neil/Sysop) I think what with the consensus last week on this point... and we will be having that comp/decomp standards... COs shortly.... Any comments from anyone on this point? (18,Clay Maeckel) How will an off the shelf program... know what value to put in for the total... length if it was not the program that... packed it, or is the packing programs... going to have to do the upload also. ga (18,Don Brown/Sysop) Clay, the figure would only be able to be filled in... with programs that pack and compress on the fly. ... Harry,... the problem with your idea is that it would lock us... into Packit yet, this is more general, and I don't think... we know enough yet to pick a packing/compression algorithm yet. ga (18,Harry Chesley) It wouldn't really lock you into PackIt. At least not into PackIt compression... algorithms. You can just use a different subfile type and have an entirely.. different compression algorithm. ga (18,Neil/Sysop) If I can just interject... Unless I'm wrong, didn't we discuss this last week? I would hate to... change something that was already consensed upon... but I am not limiting discussion I just want to point out that I think we have to stay with agreements as they are made.. just my thought (18,Don Brown/Sysop) Yes, I'm afraid this is a bit of a rehash. Anybody else, though, want to reconsider this position? ga (18,Harry Chesley) I said my bit, so don't hold up on account of me. ga (18,Neil/Sysop) Let me just ask both Bill Bond and Jean Hess a question... Bill, is there anything in the proposal/amendments that would make... it difficult to be implemented in Freeterm2? And Jean, likewise, that would make it difficult for Hayes to accept for some reason? (18,William Bond) I don't see any problem... I think compression/packing is an endless... discussion that maybe should be put off... for a while. ga (18,Jean Hess) I don't see any problem, either. I do agree with Bill that packing/compression is something which shouldn't be made mandatory. Adding a size, and making it optional is another matter, I guess. When we get to the second header stuff, I do have one question. ga (18,William Bond) I'm not sure that I like the idea... of a flag for another block... especially, if we have no reason for it... right now, why define it?... I quess I like "standards" without options. ga (18,Don Brown/Sysop) Here's one scenario. In August, Apple announces... System 4.2 (this is hypothetical, BTW), and in it, they... implement two new traps, _GetFileComment and _PutFileComment. ... We decide then that it'd be nice to include it in the file... transfers, as an additional header block. On the other hand,... since it isn't vital to the integrity of the file,... we'd like to let WonderTerm download the file, skipping the... header. So, we agree a standard on including the comment... for MacBinary 2 version 130. However, we don't... increase the minimum version needed to read it. Old WonderTerm... downloads a file with it, sees that there's a header,... skips it, and gets the file perfectly. That's one... possibility where it'd be useful. There might be others... as well, it's just a method of allowing minor... future tinkering without obsoleting all old programs if possible. (18,Jean Hess) Wasn't there a provision in the original MacBinary standard specifically for that purpose? ga (18,Don Brown/Sysop) Looking now, I don't see it, though I have... a vague memory of it. Anybody else help me out? (18,Peter Olson/ICONtac) The original standard allowed for information following ... the end of the resource fork BUT ... I think it would be better to have such additional ... info specified, since a bad upload could ... have information at the end of the file by accident (18,Jean Hess) Sorry, I don't have a copy of the standard here. But I'm sure I remember there being something in the header, which if non-zero, meant that an additional block followed somewhere, maybe after the header. I thought it was intended for holding file comments in the future. I certainly remember implementing something like that. ga (18,William Bond) Peter has it right (18,Don Brown/Sysop) Okay, I found it. Yes, the info comment... was to be after the resource fork, but also the length was... in bytes 99 †100. Hmm, if anyone implemented this, that... would cause a rather neat crash when we start putting flags... into byte 99. Perhaps we should move the additional finder... flags into byte 101. However,... that was just one scenario about why we might want... something else. I'd still say let's keep the secondary... header flag, just in case. Should be easy to... program, and no harm done if it's never implemented. (18,Neil/Sysop) OK but in 99 or 101? ga (18,Jean Hess) The byte 99 thing is implemented in Smartcom. I won't say that it works correctly, necessarily, but I vote for moving the new stuff. ga (18,Neil/Sysop) I feel if 99 is defined in MacBin 1 we are constrained... to go to byte 101. Any comments? ga (18,Larry Loeb/BIX) 101 (18,Don Brown/Sysop) 101 (18,Mark Hagerman) 101 (18,Clay Maeckel) 101 (18,Neil/Sysop) Anyone NOT in favor of 101? (18,Peter Olson/ICONtac) 101 (18,Michael Pester) 101 (18,Neil/Sysop) OK, yay! (18,Bill Davis) 101 (18,Neil/Sysop) Don could you recap for us the various changes.... one at a time and we can see if there is any further... discussion on each point and, if not, I guess move to... a vote. ga (18,Don Brown/Sysop) OK. I'll give the four changes, and after each change, if you... object to it or want more conversation, say "No on this". Ammendment #0--Do NOT clear bit six, shared bit, because... it's needed by Appleshare. Any objections? Ammendment#1 The word at offset 120 will hold the length of a secondary header, to be skipped when decoding a MBII file. This is for future expansion, if we decide to add a second header, but that the information in such header is not vital to decoding a MBII file. (Of course, such a change WILL involve making the files incompatible with MacBinary I.) MBII should currently zero this number. Do people want more discussion on this? Ammendment#2 The longword at offset 116 may optionally hold the total disk space used by all files if the MBII file represents a packed, compressed set of files. This is for the convenience of any program that packs and unpacks on the fly and can be ignored by most implementations of MBII. If the value here is zero, it means that this value is Unknown. MBII uploading programs that do not have a proper value to fill this field with must make sure it is zeroed. (18,William Bond) I don't like #1, but assuming other do... does length have to be a multiple of 128 (I hope) ga (18,Don Brown/Sysop) Okay, looks like we've got more discussion on 1. We'll... get back to it in a moment, does #2 pass everyone's approval? Speak... now or hold your peace. <grin> Finally,... Ammendment#3 The byte for extra finder flags will be at byte 101 instead of byte 99 That already got passed, so my understanding of the... group feeling is that 0, 2, and 3 are in the proposal. Have... I missed anybody's objections? OK, I guess we're ready to get back to #1. Bill, I'd... have no problem with it being a multiple of 128,... what does anyone else think? (18,Jean Hess) This is in general...It kind of bothers me that this is going to make II incompatible with I. Since the original standard defined bytes 99 and 100 (or whatever) as being the length of an additional header, couldn't we just use those, instead of adding more? Maybe I'm not remembering correctly, since I don't have the standard here. ga (18,Don Brown/Sysop) Just wanted to point out that it does NOT make it incompatible... yet, would only be incompatible if we wanted to set up a 2.1... at some point that used the header. On the other hande, since... we've got that in MacBinary I already, we could just junk... the whole idea, and use that header instead. (18,Jean Hess) Is there a difference in what's defined in I as the purpose of the bytes, and what your intention was for II? ga (18,Don Brown/Sysop) OK. MacBinary 1 specifies that it is exactly for... GetInfo comments. The second header in MacBinary 2 had... no real purpose hooked up to it, it was just thought... we might need one in the future sometime, and the... GetInfo comment was one potential use. My personal guess is... that we'll never implement the second header, but... I've been wrong before betting on the future, and it... seemed like a painless way of providing some expansion... capability. (18,Peter Olson/ICONtac) Don, if I understand your reading of the ... standard properly earlier in the CO, the ... 99.100 length refers to data at the end of the transfer, not the ... beginning, where it might be needed. I like the proposal for the optional length of a secondary header as it has been ... proposed also, I have a comment on Bill's suggest on 128 byte rounding (18,William Bond) The problem with extra data as a header is that it will break any program that does not expect it. A trailer or additions to the MacBinary header does not cause this problem. (18,Don Brown/Sysop) It'll only break in the future if we decide we need to add... a second header at the start. If we implement the header as... a header count NOW, then MacBinary 2.0 (what we're doing... now) will not break MacBinary 1.0 (because the header... is zero). If we need that header for MacBinary 2.1,... it will break MacBinary 1.0 (since it won't... know how to deal with that header) but won't break... MacBinary 2.0. Just want to repeat, that this is hypothetical,... here may never be a 2.1, and nothing may ever change. Now ga. (18,Jean Hess) Don, what is the description of the byte 99 length in 1.0? Does it follow the header, or does it follow the file? ga (18,Don Brown/Sysop) In the MacBinary 1 plan, bytes 99 †100 make up a word length... of a get info comment that is placed... after the final fork is transmitted. It goes... at the end. (18,Larry Loeb/BIX) I've been thinking ... (surprise!) that maybe a trailer *is*.. a Good Idea. Maybe a MacB 2.1 would... know that it's there;but I dont see it.. breaking MacB I (which makes me .. *very* nervous) because the MacB I would ignore the trailer, yes? (18,Don Brown/Sysop) I agree. Let's sort of undefine the trailer from... MacBinary 1 from being specifically for GetInfo comments,... and change it instead to an optional trailer, whose... length is in the word starting at 99. Any disagreements? ga (18,Peter Olson/ICONtac) beginning of the transfer? (such as a sdifferent ... solution to the packing problem) ... by allowing for a secondary header now, we ... provide an orderly path for the future (18,Larry Loeb/BIX) ouch. (18,Mark Hagerman) Personally, I think there should be provision for... both additional header AND trailer data, but that... the indicator should show the number of 128-byte blocks... in each one. Probably, a one-byte field would... serve for each one (header and trailer). ga (18,Jean Hess) I don't have a problem with adding the 2nd header size as the number of blocks following the first header, since it's not going to break anything right away. I don't think that we should go changing the definition of bytes 99 and 100 as specified in the original standard, though. ga (18,Mark Hagerman) You're right. (18,Larry Loeb/BIX) I withdraw the Good Idea.. Let me apologise for being late... It was a good weekend. It is becoming obvious to me that y'all are discussing something a bit different from what is now in DL6. Can I get a very short summary? I also have some comments on that doc and several improvements, but want to wait until y'all are ready. (18,Neil/Sysop) Jack we cannot backtrack at present... it would be too confusing... Basically the amendments as... listed on the board and in the DL have been passed with... the exception of the the one dealing with bytes to reference a,... possible second header which is the issue now under discussion... It looks like we are back to accepting that amendment? Or... do we have more comments directly on that amendment? ga (18,Peter Olson/ICONtac) I like the idea of rounding the size of the ... secondary header to an even multiple of 128 ... exactly in the same fashion the data fork and ... resource fork are treated now (ie, if the ... number in the primary header reads 235, the ... number of bytes allocated to the secondary header is 256) (18,Neil/Sysop) Yes, I think that everyone appears to like... the multyiple-of-128 (18,Clay Maeckel) If we go with the 128 deal, we could put it in byte 82 to make sure that MacBinary I will not read it. ga (18,Larry Loeb/BIX) wont MacB 1 blow up on that? [one way of getting it not to read it...] (18,Neil/Sysop) Don, could you summarize where we are? <hehe> ga (18,Don Brown/Sysop) OK, I'll try. As I see it, we are considering what to do to... support a potential future additional block. We can... (1) Do what the proposal was, where we put the length... in two bytes that escape me at the moment, which a... MacBinary II file will skip. If this is done,... we need to put something non-zero into byte 82, so that... MacBinary I won't get confused if we try it, or... (2) we put the block as a trailer, with the length in... bytes 99 †100. The flaw with 2 is that we might... need the info before we download the file, if it's... used for something like unpacking. Have I... misstated anyone's position? ga (18,Clay Maeckel) We might as well make byte 82 useful.. as the number of 128 byte blocks used.. as the header instead of using the two.. bytes else where. ga (18,Don Brown/Sysop) That's right, skipped that. Consider it (1a). (18,Don Brown/Sysop) Any other comments/discussion, or are we ready for a vote? (18,Peter Olson/ICONtac) we might want to break Macbinary I without allocating ... any secondary header blocks ... Clay's proposal ... prevents that (18,Larry Loeb/BIX) peabo: .... what other functions besides... comp/decomp can you see... needing this kind of into on the fly?.. I can see not having to build a temp file... during download . That's why a header may.. be used instead of a trailer... Is there any other function (ignoring the... other obvious encryption application... that has the same need for reduced... user disk pace.) Do we need headers *and* trailers available? (18,Peter Olson/ICONtac) for example, making a list of the true sizes of all ... the files in the package, external to the ... packing format, so the program can size the disk ... and prepare for a disk swap ... however, like Don, I don't like betting against ... the future, so I'd like a header available ... for 1988 implementations I don't think decomp needs temporary files ... (18,Don Brown/Sysop) OK, let's vote. If you want a header, type 1. Else, type 2. We'll decide... how to flag that header if any next. (18,Mark Hagerman) 1 (18,Larry Loeb/BIX) 1 (18,Jean Hess) 1 (18,Peter Olson/ICONtac) 1 (18,Raines/BMUG) 1 (18,H.Conover/Alt.Sysop) 1 (18,Clay Maeckel) 1 (18,Neil/Sysop) 1 (18,H.Conover/Alt.Sysop) Looks like it's #2 then, right ? (18,Don Brown/Sysop) Okay, looks like we've got a header. So,... where do we put the length? If you want the number of 128... byte blocks in byte 82, type 82. Else, type 120 (where the... word length goes). (If you don't have a preference, type "don't care"). (18,Jean Hess) 120 (18,Peter Olson/ICONtac) 120 (18,William Bond) 82 (18,Harry Chesley) 120 (18,Clay Maeckel) 82 (18,H.Conover/Alt.Sysop) 120 (18,Mark Hagerman) abstain (18,Larry Loeb/BIX) dont care (18,Neil/Sysop) don't care (18,H.Conover/Alt.Sysop) can't dance (18,Raines/BMUG) je ne sais pas. (18,Jack Brindle) 120] (18,Don Brown/Sysop) Okay, by a slight preference, it's 120. Finally, anybody... object to stating that the size should be rounded up to 128... byte increment? Say "OK" or "don't round", please. (Someday I'll figure out how to phrase things clearly) (18,Peter Olson/ICONtac) OK (18,Neil/Sysop) ok (18,Larry Loeb/BIX) er--Ok (18,Mark Hagerman) ok (18,Clay Maeckel) OK (18,Harry Chesley) errrr... OK (18,Jean Hess) Does this mean the sender must force it, or the receiver will be smart enough to take care of it (even 128 bytes)? (18,Don Brown/Sysop) If we do decide to use this header in the... future, I'd push for having the protocol insist on a 128... byte increment, but just in case, what I'm suggesting... is that the receiving program take the length and round... up if necessary, if it isn't a multiple of 128. clear? (18,Jean Hess) That's fine. ga (18,Neil/Sysop) yes (18,Mark Hagerman) transmitting routine should force it (18,Don Brown/Sysop) Okay, looks like that's all cleared up. So, bytes 120 †121 will... have the length of an optional header. A MB2 reading program... should take the value there, round it up to 128 bytes,... and skip that many bytes. A MB2 sending program should... make sure the word is zeroed. Now, any other proposed changes to the MB proposal? (18,Neil/Sysop) The format is obviously smart enough to know what it is... but for the user do we need a new suffix such as .BI2? I can... see where that might come in handy in some scenarios. ga (18,Don Brown/Sysop) Well, my thought would be that we don't need it yet,... because at the moment, we're backwards compatible, but... anyone else have a comment? (18,Neil/Sysop) OK, here is why I would like to have it.... There are rumours that one software company on their own... is revamping MacBinary..... And it may or may not be compatible with what we have here.. I asked them to be here, they said they wouldbe, they are not... If the USER must pick BI2 as a suffix that means the user will... determine if he or she has an acceptable MacBinary II term program... before uploading which a rogue program might not do. ga (18,Jack Brindle) I tend to agree with Niel... He has touched on one of the points I would like to make, but within the format. It seems to me the biggest problem we have in MacBinary is difficulty in recognition. The problems we are trying to resolve are caused by using bytes that just happened, at one time, to be defined as zero. I believe we need to add a recognition signature to the format so that there is no doubt what kind of format we have. This would greatly reduce problems when we again modify the format in the future. The form of the signature should be four bytes similar to the fdType field, except containing something like: BIN2 or MBN2 or whatever. (18,Larry Loeb/BIX) The signature I thought was taken... care of by the version numbers in the main spec... Point2: I disagree with needing an additional suffix... UNTIL it breaks MacB I... If SV wants to extend the protocol.. on their own; let 'em. The price they pay... for non-conforming is the users overloading... the telephone support line and not buying the product. (18,Don Brown/Sysop) One point--the recognition was going to be by the version... number, and also the CRC, I don't think we need an explicit... signature. Go, Jack, then Peter. (18,Jack Brindle) Well, I guess I need to sell harder. When a file comes into a machine, there is nothing really to seperate it from any other data stream. The format we defined could actually be something else. Someone doing a program that tries to recognize several formats could tear their hair out figuring what was what. In fact many systems have, for example, PC and Mac programs sitting side by side. We really don't have anything concrete that seperates the two. Point two. What do we do when Apple activates the ioFlVersNum field? Do we then modify the format to re-add that field? That is now used for format recognition! By adding special recognition characters, we remove all doubt and force the issue. Now, as for supporting the MacBinary product, I can tell you what our policy will be... We will support MacBinary I, and whatever Apple is doing with their file transfer protocol. ga (18,Harry Chesley) (I have to get going. I'll catch it on the transcript. See y'all later.) (18,Don Brown/Sysop) Harry, can you wait just a second? I think we're almost ready for a vote here. Go ahead, Peabo, then let's try for a final consensus (18,Peter Olson/ICONtac) Jack, the CRC is very secure for ... recognition, and I think that ... the ioFlVersNum filed died with MFS ... Point two: ... The difficulty with Software Ventures is ... not entirely their fault ... yes, they should have pushed for an earlier ... scheduling of THIS CO, and they didn't, ... but we have to recognize they were ... under pressure to release a product ... for other reasons. I'd like to know ... just what they ARE going to do with ... the product delivery mess they are ... now in as a result of possible ... differences between their ... implementation and what we are ... recommending. It concerns us ... all, I think. (18,Larry Loeb/BIX) patch (18,Peter Olson/ICONtac) a patch is technically easy but the ... problem is distributing it (18,Don Brown/Sysop) OK, it's getting late, let's go for some votes. Bill,... is it vital? (18,Don Brown/Sysop) Bill? (18,William Bond) Has SV released any doc on what they did? (18,Neil/Sysop) Bill, no. (18,Don Brown/Sysop) Not yet, Bill, we were hoping they'd be here. Nobody... here knows, correct? (18,Neil/Sysop) (I spoke to Mike Quinn Weds and he said he'd be here) (18,Larry Loeb/BIX) Neil: then you did all you could. (18,Don Brown/Sysop) Okay, let's make some decisions and put this baby to rest. 1. Do we need to add a character signature to the header?... Please type "yes" or "no" (18,Peter Olson/ICONtac) no (18,Larry Loeb/BIX) no (18,Neil/Sysop) no (18,Don Brown/Sysop) The character signature is defeated, then. 2. Do we need to change the "standard" 3 letter suffix... for MacBinary 2 files, given that they're still... backwards compatible? Please type "yes" or "no" (18,Larry Loeb/BIX) not yet (18,Jean Hess) no (18,Neil/Sysop) no (I gess) (18,Clay Maeckel) no (18,Don Brown/Sysop) Okay, so neither the character signature or the change... in suffix are adopted. Do people want to close off all... futher amendments to the current proposal? yes or no. (18,Peter Olson/ICONtac) yes (18,Larry Loeb/BIX) aye (18,Neil/Sysop) yes (18,Clay Maeckel) yes (18,Don Brown/Sysop) Okay, we're done with amendments. We now come to the big... one. We have the proposal, amended so that we don't... clear bit 6 of the finder flags, we move the byte of... extra finder flags to byte 101, we have a header length.. in bytes 120 †121, and an optional total unpacked... length in bytes 116-119. IS THE PROPOSAL ADOPTED? Type yes or no. (18,Peter Olson/ICONtac) yes! (18,Neil/Sysop) yes! (18,Jean Hess) yes (18,Clay Maeckel) yes (18,William Bond) yes (18,Neil/Sysop) Great! (18,Don Brown/Sysop) Okay, we've got a proposal (18,Neil/Sysop) OK (18,Neil/Sysop) I'd just like to point out that this proposal will only... really work if everyone involved keeps pushing it so let's all... make sure that this is disseminated as widely as possible... and I will let Dan C. know that we have something coming up for... the next Software Supplement addition as last time... (18,Larry Loeb/BIX) Have their been any "official" comments on... draft 1 from Apple. Besides Perez, I mean...[grin] (18,Neil/Sysop) Not as such but we did have a couple Apple.... people here last week so this is not much different ... at all since then. I think we will not have problems from that.. end anyway. ga (18,Don Brown/Sysop) BTW, I think as a follow up, we need to schedule a... conference for a few weeks from now for a "recommended".. packing/compression algorithm to use in conjunction with... MacBinary 2. It may be Packit, it may not, but we all need... time to investigate it first. Should we try to... schedule such a conference? (18,Neil/Sysop) How's July 19? (18,Neil/Sysop) (a Sunday) (18,Peter Olson/ICONtac) fine with me (18,Don Brown/Sysop) Sounds good to me. Let's get the word out on that. Any... final comments from anyone? (18,Larry Loeb/BIX) who knows? I live 20 minutes at a time.. (18,William Bond) Good! A co where everyone will agree. (18,Peter Olson/ICONtac) Bill :-) (18,Neil/Sysop) Just that we all deserve a round of applause! (18,Neil/Sysop) <clap!!!!> (18,Don Brown/Sysop) Bill, you willing to make book on that? (18,Don Brown/Sysop) I guess we're adjourned!